This disclosure relates to detecting software memory leaks and, more particularly, to detecting methods that cause memory leaks in garbage collected code.
Memory leaks pose a problem in software development. Sometimes the code within a software application will allocate memory, but will never release the memory. If the software application never releases the memory, the memory is tied up and the computer system is unable to use the memory. A typical situation occurs where a software developer, using a traditional language such as C, calls the standard C function “void*malloc(size_t size)” (which allocates and reserves a block of memory) but fails to call the standard C function “void free(void*pointer)” (which de-allocates a block of memory and makes the block of memory available for use) when the memory is no longer needed. The result is that the memory is tied up and cannot be used, even though the application that tied up the memory is no longer using the memory.
Some software run-time environments attempt to prevent memory leaks by employing a garbage collection function. For example, the Java® run-time environment and the .NET™ run-time environment both include a garbage collection module (Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both; .NET is a trademark of Microsoft Corporation in the United States, other countries, or both). One of the garbage collector's tasks is to find memory that is no longer in use and de-allocate the memory so that it is free to be used by other software.
Garbage collectors, however, typically operate by walking through an object reference graph (“ORG”) to determine if memory is currently being used. The ORG may include information about each software object in the software application as well as information about pointers to each software object, and may link software objects to the memory that they use. Typically, a garbage collector will release memory associated with an object when there are no pointers or references to the object in the object reference graph.
Memory leaks may still occur in a garbage collected environment, however. In a garbage collected environment, a memory leak may occur when an object is referenced for a long time without being used. As long as something in the ORG is referencing an object, the garbage collector cannot free the memory associated with the object. For example, an object may be assigned to a static or global variable that is never used by the software application. Since there is a reference to the object, the garbage collector cannot free the memory associated with the object, even though the object may never be used by the software application.
The object reference graph solution may also pose other problems, as well. For example, object reference graphs in many cases may be obtained only after a garbage collection. Also, each garbage collection may produce a new object reference graph. In a typical program, object reference graphs may include many objects with many links between them. An exhaustive analysis of such graph may be difficult to implement and may be time consuming. It may also be difficult to associate objects in the reference graph with code responsible for their creation. There may be no direct link between the structure of an object reference graph and the lifetime of objects in this graph. Many of the existing automatic reference graph analysis methods are based on heuristic algorithms that rely on certain assumptions and conditions, which are not universal. The object reference graph may be a large graph or file that holds a lot of information. It can be unwieldy and time consuming for a garbage collector to walk through the object reference graph searching for memory without any pointers. Also, the object reference graph may change each time the garbage collector de-allocates memory.